The present invention relates in general to the field of computers and other data processing systems, including hardware, software and processes. More particularly, the present invention pertains to the management of the resources of a data processing system using rules that are resource-based.
A computer system may have many resources as part of the system. These resources include both hardware (client computers, servers, printers, storage devices, etc.) as well as software (operating systems, applications, etc). Such resources are often given technical support by a central logic, which may include a rule system. Utilization of a rule in a rule system may be either through a “pull” or a “push”.
For an example of a “pull,” consider FIG. 1a. A resource 102 is supported by a rule system 104, which includes a miles logic 106 that interacts with a rules database 108. Assume for exemplary purposes that resource 102 is a server. Resource 102 “knows” that rule system 104 has a rule in rules database 108 related to how a Central Processing Unit (CPU) 110 in resource 102 is to be managed, but resource 102 does not “know” exactly how the CPU 110 is to be managed. Thus, resource 102 will (step 1) send a “pull” rule call to rule system 104, asking rule system 104 to process the appropriate rule for managing the CPU 110. Rule system 104 uses a descriptor language, such as Web Services Description Language (WSDL), to understand what data can be “pulled” from resource 102 to process that requested rule. This data is then requested by the rule system 104 from the resource 102 (i.e., “pulled”—step 2), resulting in the resource 102 sending the appropriate input data (step 3) for the rule. Rule system 104 then uses the rules logic 106 to apply the input data to the appropriate rule, and outputs the result data (step 4) to the resource 102.
For exemplary purposes shown in FIG. 1a, then, assume that there is a rule in rules database 108 that states “If CPU utilization exceeds 70% for three consecutive samplings, then disable low priority software processes.” If CPU 110 actually exceeds 70% utilization for three consecutive samplings, then after Steps 1-4 execute, low priority processing will be disabled, preventing them from using any of CPU 110's capacity.
The example described above is only exemplary. Specifically, such a rule may also apply to software resources. That is, consider the example of resource 102 actually being a software program, rather than the server described above. This software program may “know” that discount pricing should be given to certain orders, but doesn't “know” any details about when such discounts should be given, or for how much. Thus, the resource 102 will send a request (step 1) for a rule about pricing to the rule system 104, which will (using WSDL to determine what data can be pulled) pull data (step 2) regarding how large the order is. The resource 102 will then respond with the order size (e.g., dollar amount), as shown in step 3. The rule system 104 will then respond with how much the order should be discounted (step 4).
Another type of rule utilization is known as a “push” system. A “push” may be synchronous or asynchronous. Consider first a “synchronous push,” as described in FIG. 1b. In this scenario, the resource 102 “knows” not only what rule it needs (from rules database 108), but resource 102 also knows what input parameters are needed for the needed rule. Thus, the resource 102 concurrently sends a request for a particular rule in rules database 108 as well as the necessary input data (step 1). The rule system 104 then uses rules logic 106 to apply the received input data to the requested rule from rules database 108, and sends the output data (which results from the input data being applied to the particular rule) to the resource 102 (step 2). Note that while the systems shown in FIGS. 1a and 1b are similar, in FIG. 1a, the rule system 104 subsequently goes back to the resource 102 to ask for the additional information (shown in the “Pull for Value” Step 2 in FIG. 1a).
While FIG. 1a and FIG. 1b demonstrate differing “pull” and “synchronous push” systems, they are similar in that both systems described in FIGS. 1a-b permit a rules engine to query a resource for data. This is not the case, however, in an “asynchronous push” system.
FIG. 1c describes such an “asynchronous push,” in which data is pushed to the rule system 104, but without a request for a particular rule. Unfortunately, this scenario is common in computer systems. That is, resources 102 routinely send a wide variety of event data to a central manager, which may include a rule system 104. For example, if the resource 102 is a server, then the event data may be for such disparate items as outside temperature, CPU utilization, page swapping, local time of day, clock speeds, number of users that are logged on, etc. This central manager and its associated rule system 104 does not “know” what to do with the event data that is received. More specifically, the rule system 104 does not know which rule in the rules database 108 is appropriate for the received asynchronous data.